The IEEE standard, “IEEE 1394-2000 Standard For A High Performance Serial Bus,” Draft ratified in 2000, is an international standard for implementing an inexpensive high-speed serial bus architecture which supports both asynchronous and isochronous format data transfers. Isochronous data transfers are real-time transfers which take place such that the time intervals between significant instances have the same duration at both the transmitting and receiving applications. Each packet of data transferred isochronously is transferred in its own time period. An example of an ideal application for the transfer of data isochronously would be from a video recorder to a television set. The video recorder records images and sounds and saves the data in discrete chunks or packets. The video recorder then transfers each packet, representing the image and sound recorded over a limited time period, during that time period, for display by the television set. The IEEE 1394-2000 serial bus architecture provides multiple channels for isochronous data transfer between applications. A six bit channel number is broadcast with the data to ensure reception by the appropriate application. This allows multiple applications to simultaneously transmit isochronous data across the bus structure. Asynchronous transfers are traditional data transfer operations which take place as soon as possible and transfer an amount of data from a source to a destination.
The IEEE 1394-2000 standard provides a high-speed serial bus for interconnecting digital devices thereby providing a universal I/O connection. The IEEE 1394-2000 standard defines a digital interface for the applications thereby eliminating the need for an application to convert digital data to analog data before it is transmitted across the bus. Correspondingly, a receiving application will receive digital data from the bus, not analog data, and will therefore not be required to convert analog data to digital data. The cable required by the IEEE 1394-2000 standard is very thin in size compared to other bulkier cables used to connect such devices. Devices can be added and removed from an IEEE 1394-2000 bus while the bus is active. If a device is so added or removed the bus will then automatically reconfigure itself for transmitting data between the then existing nodes. A node is considered a logical entity with a unique address on the bus structure. Each node provides a configuration ROM, a standardized set of control registers and its own address space. Because of these advantages the IEEE 1394-2000 standard provides for a unique networking structure that is capable of incorporating audio/video devices, media play/record devices, computing devices and display devices.
The IEEE 1394-2000 standard defines a protocol as illustrated in FIG. 1. This protocol includes a serial bus management block 10 coupled to a transaction layer 12, a link layer 14 and a physical layer 16. The physical layer 16 provides the electrical and mechanical connection between a device or application and the IEEE 1394-2000 cable. The physical layer 16 also provides arbitration to ensure that all devices coupled to the IEEE 1394-2000 bus have access to the bus as well as actual data transmission and reception. The link layer 14 provides data packet delivery service for both asynchronous and isochronous data packet transport. This supports both asynchronous data transport, using an acknowledgement protocol, and isochronous data transport, providing real-time guaranteed bandwidth protocol for just-in-time data delivery. The transaction layer 12 supports the commands necessary to complete asynchronous data transfers, including read, write and lock. The transaction layer 12 also provides a path for isochronous management data to be transferred to the serial bus management block 10 via read operations with isochronous control compare-swap registers. The serial bus management block 10 contains an isochronous resource manager for managing isochronous data transfers. The serial bus management block 10 also provides overall configuration control of the serial bus in the form of optimizing arbitration timing, guarantee of adequate electrical power for all devices on the bus, assignment of the cycle master, assignment of isochronous channel and bandwidth resources and basic notification of errors.
A diverse range of products can be implemented with the ability to connect to an IEEE 1394-2000 serial bus network. These devices can have capabilities and functionality ranging from very simple to very complex. Specifically, a variety of audio/video devices, media play/record devices and computing/display devices are capable of being linked together over an IEEE 1394-2000 serial bus networking structure to support asynchronous and isochronous data transfers between the devices.
The IEEE 1394-2000 serial bus allows a collection of devices to work together in a high bandwidth, distributed environment to maximize the overall efficiency and functionality of the network. This allows manufacturers to remove expensive pieces of functionality from one device and locate that functionality in another device on the network, instead of duplicating this functionality in all devices on the network. While some of the devices have limited functionality and are relatively inexpensive, such devices require the support and interaction of other devices in order to bring the full functionality of the devices within the network to the user.
The AV/C Digital Interface Command Set is a command set used for data transactions between consumer audio/video equipment over an IEEE 1394-2000 serial bus. Neither the IEEE 1394-2000 serial bus nor the AV/C command set provide a master-slave relationship between the devices coupled within the IEEE 1394-2000 serial bus network. Instead, both the IEEE 1394-2000 serial bus and the AV/C command set operate based on a cooperative peer-to-peer coexistence of devices within the network. Discrete AV/C command and response data packets are transferred between networked devices over an IEEE 1394-2000 serial bus in an asynchronous data stream. The AV/C command and response data packets are typically formatted according to the AV/C protocol outlined in the AV/C Digital Interface Command Set. Transfers of AV/C command and response data packets over the IEEE 1394-2000 serial bus network are supported by an AV/C architecture. The AV/C architecture is used by devices to create, process and/or transmit AV/C command and response data packets.
The target device is controllable by a controller device that initiates desired data transactions. The desired data transactions are IEEE 1394-2000 write transactions, wherein a controller device requests a target device to perform a task. The data transactions are contained within command and response frames of the command and request data packets which are formatted according to the Function Control Protocol (FCP) and then transferred asynchronously between device nodes on the IEEE 1394-2000 serial bus.
A format of a block write packet 30 according to the IEEE 1394-2000 standard is illustrated in FIG. 2. The asynchronous block write packet includes a header 31 and a data payload 32. The header 31 includes the fields destination_ID, t1, rt, tcode, pri, source_ID, destination_offset, data_length, extended_tcode and header_crc. The destination_ID field is a sixteen bit field which specifies the node ID of the receiving node to which the packet is addressed. The transaction label field t1 is a six bit field that specifies a unique tag for each outstanding transaction from a node. The retry code field rt is a two bit field which specifies whether the packet is a retry attempt and the retry protocol to be followed by the destination node. The transaction code field tcode is a four bit field that specifies the packet format and the type of transaction that is to be performed. For a write request for data block operation the transaction code field value is equal to 0001.
The priority field pri is a four bit field that is used by the back plane. The source-ID field is a sixteen bit field that specifies the node ID of the transmitting node of the packet. The destination offset field is a forty-eight bit field that specifies the forty-eight bits of the destination node address of the request packet. The data length field is a sixteen bit field that specifies the length of the data field of data block payload packets. The extended transaction code field extended_tcode is a sixteen bit field that conventionally is only meaningful if the transaction code field indicates a lock request or lock response packet. The header_CRC field is a thirty-two bit field that is used to perform a cyclical redundancy check (CRC) on the data within the header.
The data portion of the packet includes a data block payload field and a data_crc field. The data_crc field is a thirty-two bit field that is used to perform a cyclical redundancy check (CRC) on the data within the data portion of the packet.
AV/C command and response data packets are transmitted between networked devices using the FCP data fields of the asynchronous write packet 30, and have the format illustrated in FIG. 2 and described above. The data packets are transmitted over the serial bus and received by a device with the appropriate destination address. Using a read transaction, data at a particular address within a responding node is transferred back to a requesting node. Using a write transaction, data is transferred from a requesting node to a particular address within one or more responding nodes. Using lock transactions, data is transferred from a requesting node to a responding node, processed with data at a particular address within the responding node and the result is then transferred back to the requesting node.
Again referring to FIG. 2, the data payload frame 33 is organized into a sequence of data fields according to the Function Control Protocol (FCP) defined by the standard IEC 61883, Digital Interface For Consumer Audio/Video. The Function Control Protocol frame provides a simple format to encapsulate device command and response data sets within the IEEE 1394-2000 serial bus for asynchronous block read and write data transactions. The payload of the FCP frame 33 is limited to a maximum of 512 bytes.
FIGS. 3A and 3B show a detailed command FCP data frame 40 and a response FCP data frame 50 formatted in accordance with the standard AV/C protocol. The first data fields in both of the data frames 40 and 50 are the cts data fields 41 and 51, respectively. The cts data fields 41 and 51 hold 4 bits of data each and define the transaction format that is to be used in the FCP frames 40 and 50; the code for the standard AV/C format shown in FIGS. 3A and 3B is 0000. The ctype data field 42 and the response data field 52 are also 4 bits in length and encode the data packets 40 and 50 for the type of command or response data transaction. For example, a command frame such as the one shown in FIG. 3A, may be encoded for a control command, an inquiry command or any other data transaction that is required. The subunit type and the subunit ID data fields 43 and 53 encode the data packets 40 and 50 for the resource subunit within the device that is being used to execute the command data set. For example, the command packet may be issued to start a display of a video monitor, to turn on/off a tuner, turn on/off a recorder and the like. Since several subunit resources may belong to the same device or belong to the same device node address, the subunit type and ID is used to distinguish them. The opcode data fields 44 and 54 code the data packets 40 and 50 for the device operation to be executed and the operand data fields define the parameters of the operation to be executed.
As described above, the ctype data field 42 is 4 bits in length and encodes the command data packet 40 for the type of command data transaction included within the data packet 40. Table I below includes the different types of commands specified and the corresponding value for each command.
TABLE IAV/C Command TypesVALUECOMMAND TYPE0CONTROL1STATUS2SPECIFIC INQUIRY3NOTIFY4GENERAL INQUIRY5-7Reserved for future specification8-F16Reserved for response codes
As described above, the response data field 52 is 4 bits in length and encodes the response data packet 50 for the type of response data transaction included within the response packet 50. Table II includes the different types of responses specified and the corresponding value for each response.
TABLE IIAV/C Response TypesVALUECOMMAND TYPE0-7Reserved for command types8NOT IMPLEMENTED9ACCEPTEDA16REJECTEDB16IN TRANSITIONC16IMPLEMENTED/STABLED16CHANGEDE16Reserved for future specificationF16INTERIM
As illustrated in Table I above, a value of 0000 within the ctype data field indicates a control command type. A control command is sent by a controller to a target device to instruct the target device to preform an operation. Either the AV unit or a subunit at the target device may be the recipient of the command, as determined by the subunit_type and subunit_ID fields in the command frame. The remaining fields, opcode and operand[n], specify the command. A target device that receives a control command shall return an AV/C reponse frame with one of the following four response codes: not implemented, accepted, rejected and interim. The not implemented response code is returned by the target device if the target device does not support the control command specified by the opcode and operand[n] filed values, or if the command is addressed to a subunit not implemented by the target device. The accepted response code is returned if the target device implements the control command specified by the opcode and operand[n] values and the target state permits execution of the command. The rejected response code is returned if the target device implements the control command specified by the opcode and operand[n] values, but the target state does not permit execution of the command. The interim response code is returned if the target device implements the control command specified by the opcode and operand[n] values, but the target device is unable to respond with either an accepted or rejected response within 100 milliseconds. Unless a subsequent bus reset causes the AV/C transaction to be aborted, after sending an interim response the target device shall ultimately return a response frame with either an accepted or rejected response.
As illustrated in Table I, a value of 0001 within the ctype data field indicates a status command type. A status command is sent by a controller to a target device to instruct the target device to request the target device's current status. Status commands may be sent to either AV units or subunits. A target device that receives a status command shall return an AV/C response frame with one of the following four response codes: not implemented, rejected, in transition and stable. The not implemented response code is returned by the target device if the target device does not support the status command specified by the opcode and operand[n] field values, or the command is addressed to a subunit not implemented by the target device. The rejected response code is returned if the target device implements the status command specified by the opcode and operand[n] values, but the target state does not permit the return of status for the command. The in transition response code is returned by the target device if the target device implements the status command specified by the opcode and operand[n] values, but the target state is in transition, possibly because of an already acknowledged command or a manual operation. A subsequent status command, at an unspecified future time, may result in the return of a stable response code. The stable response code is returned by the target device if the target device implements the status command specified by the opcode and operand[n] values and the information requested is reported in the opcode and operand[n] values in the AV/C response frame.
As illustrated in Table I, a value of 0010 within the ctype data field indicates a specific inquiry command type. Specific inquiry commands may be used by a controller to determine whether or not a target device supports a particular control command. Except for the value within the ctype data field, the AV/C command frame for a specific inquiry command is identical to the corresponding control command. A controller may reliably use specific inquiry commands to probe the capabilities of a target device, since the target device shall not modify any state nor initiate any command execution in response to a specific inquiry command. A target device that receives a specific inquiry command shall return an AV/C response frame with only one of the following two response codes: implemented or not implemented. All other fields in the response frame are exact copies of the command frame. A response of implemented specifies that the corresponding control command specified by the opcode and operand[n] values is implemented by the target device. An AV device implementation may validate all of the operands or it may validate only the opcode and enough of the operands to uniquely identify the control command and determine its support level. A response of not implemented specifies that the corresponding control command specified by the opcode and operand[n] values is not implemented by the target device.
As illustrated in Table I, a value of 0011 within the ctype data field indicates a notify command type. A controller that desires to receive notification of future changes in a target device's state may use the notify command. Responses to a notify command shall indicate the current state of the target device and then, at some indeterminate time in the future, indicate the newly changed state of the target device. A target device that receives a notify command shall not modify its state but shall generate an immediate response frame with one of the following three response codes: not implemented, rejected and interim. The not implemented response code is returned by the target device if the target device does not support the control command specified by the opcode and operand[n] field values, or the command is addressed to a subunit not implemented by the target device. The rejected response code is returned if the target device implements the event notification for the condition specified by the opcode and operand[n] values, but the target device is not able to supply the requested information. A rejected response may return if another controller requests notification of a target device's change of state. The target device then sends a rejected response to the controller indicating that the controller will no longer be notified of a change in state. The interim response code is returned if the target device supports the requested event notification and has accepted the notify command for any future change of state. The current state is indicated by the opcode and operand[n] values returned in the response frame. At some future time, the target device shall return an AV/C response frame with either a rejected or changed response code. Once a target device has accepted a notify command by the return of an interim response frame, the target device is primed to return a subsequent response frame upon the first change in the target device's state. The future change of the target device's state could be the result of an operation in progress when the notify command was received or it could be the result of a control command not yet received by the target device. A changed response code is sent if the target device supports the event notification specified by the opcode and operand[n] values and the target state differs from the target state at the time the interim response was returned. The altered target state is indicated by the opcode and operand[n] data returned in the response frame. This notification is a one-shot operation. If the controller wishes to be notified of additional changes in a target device, the controller must issue a notify command after each changed response.
As illustrated in Table I, a value of 0100 within the ctype data field indicates a general inquiry command type. General inquiry commands may be used by a controller to determine whether or not a target device supports a particular control command without being required to specify a particular set of operands for that command. The format of the general inquiry command frame consists of only the ctype data field, subunit type and subunit ID data fields and the opcode of the command which is being queried. As with the specific inquiry command, the target device shall not modify any state nor initiate any command execution in response to a general inquiry command. A target device that receives an inquiry command shall return an AV/C response frame with only one of the following two response codes: implemented or not implemented. The response frame shall also contain the opcode that was originally passed in. A response of implemented specifies that at least one of the corresponding control command variations specified by the opcode is implemented by the target device. A response of not implemented specifies that none of the corresponding control command variations specified by the opcode value is not implemented by the target device. Unlike other command types, general inquiry commands do not have a support level since they return information about the support level of the corresponding control command. However, the ability of an AV device to provide a response to a general inquiry command for any opcode is mandatory. This insures that the controller shall always receive a response to a general inquiry command.
As illustrated in Table I, the values of 0101 through 0111 are reserved for future specification and the values of 1000 through 1111 are reserved for response codes.
As described above, a controller can issue a general inquiry and specific inquiry command to a target device to determine if a target device supports a particular control command. There is currently no mechanism to determine in advance if a target device supports particular status or notify commands. With the present system, a controller can only assume that a device implements the status or notify command. When a status or notify command is issued by the controller and when a not implemented response is returned, the controller has to respond to the user in some fashion indicating that the feature supplied by the command is not supported.
In order to support existing protocols, some systems, such as Universal plug-and-play perform a query on a device and return a table of all commands supported by the device, thus providing a command feature set for the device. In order to build a table of commands supported by an AV/C target device, a controller may want to inquire for all commands prior to issuing any command. Since AV/C is structured to not provide any capability to inquire about status and notify commands, a controller which currently desires such information, must issue all of the status and notify command types sequentially to determine which commands are supported by the target device. However, this is not desirable, because issuing status and notify commands, while they do not change the state of the target device, require extra processing time and bus usage. Notify commands also may cause response frames to occur at some future time which is unknown by the controller. Further, if these response frames are pending, it is possible for a device to reject all other commands until the final notify command-type is returned.